|
|
|
|
|
|
|
might discover a class called ProcurementRuleEnforcement or GovernmentCustomer. If your client is a bank, a key entity class would be Account or Customer. Many times, such entity classes become subsystems (or packages). Use cases provide the justification for entity classes. Any entity class not addressed in a use-case model should be eliminated to avoid scope creep, when projects go off track and fall behind schedule. |
|
|
|
|
|
|
|
|
Interface classes represent the types of objects that enable the actor (human or external system) to interact with your proposed system. As Jacobson mentions in several books and magazine articles, object instances of interface classes convert inputs from the actor into events and method invocations within your system. For instance, one of your use cases for the Second Bank of Carrollton Bank Teller System is Open a New Account. After several design reviews with the users, you find that you need to have a GUI button captioned Open New Account. That button is an interface object with an associated Click event, among others. In turn, the Click event can trigger the invocation of several class methods. Because these method invocations can become complex, it isn't unusual to have a control object handle the details of invoking the proper methods. |
|
|
|
|
|
|
|
|
Control classes represent the types of objects that don't easily fit into entity or interface classes. More complex systems (and, therefore, more complex use cases) require the inclusion of control objects in your domain. Control classes can translate user inputs into method invocations on more than one entity class. For instance, if your user needs the ability to cancel an in-process request for checking account and credit history information for a particular banking customer, the user would click a Cancel button, which would then call a control object possibly named CustomerVerification, which would then invoke the appropriate methods on entity objects named CheckingAccountHistoryInfo, CreditHistoryInfo, Account, and Customer (among many possible others). Control objects control the flow of events for complex use cases. |
|
|
|
|
|
|
|
|
The Object Modeling Technique (OMT) was developed by Jim Rumbaugh to help developers capture the design specification of a proposed system. OMT is primarily based on entity/relationship modeling (Rumbaugh's background is database design) and emphasizes modeling classes, inheritance, and encapsulated behavior. The cornerstone of the OMT process includes |
|
|
|
|
|